Gobierno de Colombia

Superintendencia Financiera de Colombia

Superintendencia Financiera de Colombia

Contraste

Reducir letra

Aumentar letra

Centro de relevo

Lengua de señas

¿Aceptas nuestras Cookies?

Este sitio web usa cookies propias y de terceros para brindar una mejor experiencia al usuario en su navegación.
Si continúas en el sitio web, estás aceptando nuestras Políticas web.

 

Preguntas frecuentes MURIC

Preguntas frecuentes MURIC

No. Las API se exponen en internet y no es necesario conectarse a ninguna VPN para consumirlas.

Se utiliza el mismo usuario que la entidad usa actualmente para transmitir los formatos que serán derogados. No se requiere gestionar un nuevo usuario. La creación o actualización de usuarios se realiza a través del proceso de autogestión en la sección Trámites en línea de la página web de la SFC por el usuario administrador de cada entidad.

El token expira cada 15 minutos. Si se están realizando reenvíos automáticos o transmisiones multipart es fundamental renovar el token antes de continuar con el siguiente segmento. No existe otro timeout de conexión o inactividad adicional al del token.

Se debe realizar el envío nuevamente desde la parte 1. No es posible retomar desde la parte que generó el error.

MURIC toma para la reconstrucción del archivo la última versión de esa parte enviada. La validación de integridad se realiza mediante el checksum SHA-256 enviado al inicio; si las partes no corresponden al checksum el sistema rechaza la transmisión.

No. Las pruebas establecidas en la CE 016 de 2025 se realizarán en el ambiente productivo. No existe un ambiente de desarrollo o certificación independiente. Las pruebas solo pueden realizarse en las fechas y ventanas definidas en la circular según el grupo de adopción al que pertenece cada entidad.
Los canales principales son API REST y Superfinanciera Archivos (MTA). El canal SFTP es exclusivamente de contingencia y solo se activa cuando los dos canales principales están indisponibles. La SFC tiene la potestad de habilitar el SFTP y analiza cada solicitud de forma independiente.
El flujo es: (1) Autenticarse con usuario y contraseña (codificada en Base64 estándar RFC 4648) para obtener un token JWT. (2) Usar el token Bearer en el header Authorization de la solicitud de transmisión. (3) La comunicación se protege mediante TLS 1.2 o superior. El API soporta también Mutual TLS (mTLS). El token tiene vigencia de 15 minutos.
La consulta se puede realizar en cualquier momento a través del servicio API de consulta de estado, siempre que el API de transmisión haya generado un ID de transmisión. La respuesta incluye el estado del proceso y en caso de errores detalla el rule_id, status, message y detail de cada inconsistencia.
No. Se puede utilizar el mismo usuario con el que la entidad transmite los reportes tradicionales en ambos canales. Para el canal MTA el archivo firmado (.avro.p7z) se envía sin particionar como una única unidad.
No se genera un certificado formal. El mecanismo oficial para verificar el resultado es el servicio API de consulta de estado de la transmisión, que permite confirmar si el proceso finalizó exitosamente o si se presentaron errores.
No existe límite de transmisiones por periodo ni de reintentos ante errores del servicio. La única restricción operativa es el vencimiento del token cada 20 minutos que debe renovarse para continuar.
Base64 no es cifrado sino un mecanismo de codificación estándar (RFC 4648) que permite transportar la contraseña en el cuerpo del mensaje JSON. La protección real de la información se garantiza mediante el canal seguro HTTPS/TLS 1.2 o superior. Cualquier implementación estándar de Base64 compatible con RFC 4648 es válida.

Los servicios de MURIC derivan de la URL base de la plataforma de gestión de APIs de la SFC. Los endpoints son: Autenticación: /api/auth/ - Transmisión de archivos: /api/muric - Consulta de estado: /salida/respuesta. No existen ambientes DEV independientes; el módulo MURIC opera únicamente en ambiente productivo.

Las pruebas se realizan únicamente en las fechas establecidas en la CE 016 de 2025 según el grupo de adopción al que pertenece cada entidad. No se realizan pruebas en espacios o fechas diferentes a los definidos en la norma.
Una vez entren vigencia los plazos de la circular las entidades pueden comunicarse con la mesa de ayuda.
No. Los usuarios de transmisión están asociados al código de la entidad vigilada. Un mismo usuario no puede transmitir información de dos entidades con diferente tipo o código de entidad. Cada entidad debe contar con sus propios usuarios y credenciales.
No. El archivo AVRO no se cifra a nivel de contenido; se firma digitalmente lo cual garantiza integridad, autenticidad y no repudio. El esquema no requiere cifrado adicional del archivo ya que los mecanismos de firma y transmisión segura cubren los requisitos de seguridad establecidos.
La entidad puede elegir: enviar el stock completo cada mes o hacer una transmisión inicial masiva y luego reportar únicamente modificaciones y nuevos desembolsos. La segunda opción exige que la entidad garantice que las operaciones no incluidas están actualizadas en todos sus campos. IMPORTANTE: esta lógica de excepción aplica solo a los Insumos 1 y 2. El Insumo 3 (Movimientos) es transaccional y debe reportarse completo cada mes.
Para productos rotativos la fecha de desembolso corresponde a la fecha de creación o aprobación del cupo independientemente de si el cliente hace uso de él. El valor desembolsado es el cupo total aprobado no el monto efectivamente utilizado.
La DTF es nominal y la DTFE es la misma tasa convertida a efectiva anual. Se recomienda registrar únicamente "DTF" asegurando que el valor corresponda a la tasa efectiva anual. Los códigos DTF180 o DTF360 no deben usarse; la periodicidad va en los campos de frecuencia de pago.
El spread aplica exclusivamente para créditos pactados en tasa variable. Corresponde a la diferencia entre la tasa efectiva anual aplicada y el indicador de referencia del contrato (IBR, DTF, IPC etc.). Ejemplo: si el crédito se pactó a IBR + 5% el spread a reportar es 5%. Para créditos en tasa fija este campo va nulo.
No. Estos estados se reportan únicamente en el mes en que ocurre la novedad. Si en el mismo mes se presentan dos estados para un mismo crédito se reporta únicamente el último estado vigente a la fecha de corte. No se replica en cortes posteriores.
En el mes del pago la operación se reporta con estado Recuperación con saldos actualizados. Si el siguiente mes no hay nuevos recaudos la operación vuelve al estado Castigado y se sigue reportando con saldos actualizados indefinidamente mientras mantenga saldos pendientes.
No. Estos campos registran únicamente pagos efectivamente recibidos del deudor que representen entradas de efectivo ciertas. Los reversos, condonaciones, disputas ante franquicias y ajustes contables sin flujo real no deben reportarse. El reporte no admite valores negativos; en caso de reversión el campo refleja solo lo que el cliente pagó ese mes.
No. Los intereses contingentes corresponden a registros fuera de balance (cuentas clase 6) y no deben reportarse ni en cartera activa ni en cartera castigada. Solo se reportan los intereses ordinarios causados y pendientes de pago a la fecha de corte.
Se reporta la información de la garantía de mayor cobertura: tipo de garantía, valor del avalúo y fecha del último avalúo. Esto aplica tanto en el Insumo 1 (campos de garantía) como en los atributos correspondientes del Insumo 2. Si varias coberturas son iguales el siguiente orden de clasificación será la idoneidad. 
Son campos distintos. El marco_legal identifica si la operación tiene una normativa de excepción por reestructuración (Ley 550, 617, 1116, 1564, 2437). El código N000001 aplica para todas las operaciones que NO son reestructuraciones incluyendo castigadas, vendidas, pagadas y titularizadas. Los códigos N000R01 a N000R06 aplican solo cuando el estado es Reestructurado. Las modificaciones bajo CE 026/17 o CE 016/19 se reportan con N000001.
La entidad originadora que mantiene la administración o gestión de la cartera es responsable de reportar los tres insumos ya que posee la información primaria sobre el comportamiento del deudor. La titularizadora reporta las universalidades que administra directamente según su tipo de entidad.
La entidad debe reportar la totalidad de la cartera originada y vigente incluyendo cartera propia, castigada y operaciones objeto de transferencia o administración. No se limita a lo que hoy va en el formato 341 o 507. La cartera administrada por cuenta de terceros no se reporta.
En el mes de la operación: (1) el crédito hijo se reporta por primera vez en el Insumo 1 con nuevo identificador; (2) en el Insumo 2 se reportan el atributo 17 (tipo consolidación) y el atributo 18 (ID créditos padre); (3) los créditos padre reportan en el Insumo 3 el estado Consolidado y no se vuelven a reportar. Los créditos padre son siempre las operaciones originales que se extinguen.
Si el atributo no aplica por la tipología del deudor (ej. atributo de persona natural para una jurídica) no se crea ni reporta el registro. Si aplica pero no hay dato disponible se usa el código Sin información. No se exime del reporte por falta de datos históricos; la expectativa es completar estos campos progresivamente.
No. Los créditos cancelados por pago se reportan únicamente en el mes en que ocurre la cancelación incluyendo saldos, mora, calificación y movimientos del mes. No es necesario reportar este estado en meses posteriores ni mantener historial de periodos anteriores a la implementación del MURIC.
El campo modelo_provisiones debe reportarse con el código 3 (Sin modelo de referencia SFC). Los campos de provisión procíclica y contracíclica se reportan en cero. El campo provision_otros recoge las provisiones bajo el modelo determinístico. Para carteras Comercial y Consumo el factor K y el ajuste por plazo van inmersos en los valores de provisión procíclica y contracíclica.
No. Los ingresos utilizados para la segmentación (en SMMLV) corresponden a los capturados en el momento de la originación o asignación del cupo. El código de producto debe mantenerse constante durante toda la vida del crédito aunque el ingreso real del cliente cambie posteriormente.
Sí. Al ser tipo string la entidad tiene flexibilidad para usar la estructura que prefiera (alfanumérica, con o sin guion). Lo fundamental es que el identificador sea único, invariable en el tiempo y consistente carácter a carácter en los tres insumos. Si hay IDs duplicados entre productos distintos debe agregarse un prefijo con el código de producto.
Cuando un crédito deja de cumplir los criterios de sostenibilidad (ej. vence la certificación o cambia la composición accionaria) se debe dejar de reportar el atributo 25 (Crédito Sostenible) y actualizar todos los atributos e insumos afectados en el siguiente corte. Solo se envían los atributos que cambian.
Si la entidad no dispone del dato al momento de la implementación el atributo no es obligatorio para ese corte inicial. Sin embargo se espera que a partir de la implementación del MURIC la entidad incorpore esta marcación en los nuevos desembolsos y actualice progresivamente el stock existente en el proceso de actualización de información del cliente previsto en la Circular Básica Jurídica.
No. El único formato válido es Apache AVRO con el schema de la versión vigente publicado como anexo a la CE 016 de 2025. La extensión del archivo de envío es .avro.p7z. No se aceptan formatos alternativos como txt, Excel o CSV.
La estructura del archivo sigue el estándar Apache AVRO definido por la organización Apache. Para consultar longitud máxima de campos tipo string, manejo de nulos y demás especificaciones técnicas, las entidades deben remitirse a la documentación oficial: https://avro.apache.org/docs/1.11.1/specification/
En el archivo AVRO las fechas se serializan como un entero que representa el número de días transcurridos desde el 1 de enero de 1970 (epoch day). Por ejemplo el 31 de octubre de 2025 equivale al entero 20392. El formato YYYY-MM-DD aplica solo para la capa de negocio; la mayoría de librerías (Python, Java, Spark) realizan esta conversión automáticamente al generar el AVRO.
La compresión Snappy debe aplicarse como codec interno del archivo AVRO; es decir el archivo AVRO se genera directamente con compresión Snappy integrada. No corresponde a una compresión externa aplicada sobre el archivo ya terminado.  Se recomienda utilizar el algoritmo de compresión Snappy; no obstante, podrá emplearse cualquier otro algoritmo de compresión compatible con el formato AVRO que cumpla una función equivalente.
El flujo correcto es: (1) Generar el archivo AVRO con compresión Snappy , o cualquier otro algoritmo de compresión compatible, como codec interno. (2) Firmar digitalmente el archivo firmado quedando con extensión .avro.p7z. (3) Si supera 100 MB: particionar en segmentos para envío multipart vía API. Para el canal Superfinanciera Archivos (MTA) el archivo firmado se envía sin particionar.
No. El schema debe cumplirse de forma estricta. No se permite agregar campos adicionales al AVRO. Cualquier desviación del schema oficial muricV2.0.10.json será rechazada por el validador de la SFC.
No. Los campos definidos con tipo [null, tipo] no son obligatorios. Sin embargo para el Insumo 2 (Atributos) se debe remitir a las tablas de referencia publicadas en la página de la SFC para identificar cuáles atributos son obligatorios y cuáles aplican solo si corresponde según el tipo de deudor o producto.
Se debe enviar nuevamente el archivo completo con las correcciones correspondientes. No se permite reenviar únicamente los registros con error.
Las condiciones de rechazo incluyen: (1) Estructura del schema incorrecta. (2) Incumplimiento de reglas lógicas. (3) Incumplimiento de reglas de negocio. (4) Firma digital que no coincide con las firmas autorizadas. El sistema muestra en la respuesta el tipo de error identificado.
El checksum SHA-256 se calcula sobre el archivo AVRO completo una vez ha sido firmado digitalmente. El procedimiento es: (1) Generar el AVRO. (2) Firmarlo digitalmente. (3) Calcular el hash SHA-256 sobre el archivo ya firmado. El resultado es una cadena en formato hexadecimal que se envía junto con el archivo como mecanismo de validación de integridad.
La firma digital la realiza cada entidad de forma independiente usando el mismo certificado que actualmente emplea para la transmisión de información a la SFC. No existe un proveedor o herramienta específica definida por la SFC; la entidad puede usar el mecanismo que ya tiene habilitado siempre que cumpla los estándares de seguridad requeridos. La firma es un proceso separado de la autenticación en el API.
La llave única que vincula los tres insumos es la combinación de: identificacion_credito_entidad + tipo_identificacion + numero_identificacion. Esta combinación debe ser idéntica en los registros de los insumos MURIC-001-001, MURIC-001-002 y MURIC-001-003 para cada operación.
No. No existe un límite de reintentos ante errores 5XX o caídas del servicio. La única restricción a tener en cuenta es que el token de autenticación expira cada 20 minutos; por tanto en reenvíos automáticos se debe renovar el token antes de continuar.
No. No existe un número máximo de transmisiones por periodo. La entidad puede retransmitir el archivo las veces que sean necesarias dentro del periodo de reporte.
Los validadores contables a nivel de cuenta específica serán socializados en detalle en 2026. Mientras tanto la entidad debe verificar coherencia del capital con el Grupo 14 (Cartera de créditos por calificación y provisiones), del saldo de intereses con el Grupo 16 (Intereses por calificación) y la mora con el Grupo 82 (Cartera crediticia por altura de mora) del Catálogo Único de Información Financiera con Fines de Supervisión (CUIF).
No existe un validador local para descarga. Al momento de la transmisión el sistema de la SFC cuenta con un validador que verifica que la estructura del schema esté correctamente definida y activa los validadores lógicos y de negocio. El resultado se consulta a través del servicio API de consulta de estado.
El sistema genera una respuesta en formato JSON que incluye: tipo entidad, código entidad, fecha corte, nombre del módulo (muric), fecha de transmisión, status y una lista de errores con los campos rule_id, status, message y detail para cada inconsistencia identificada.
El MURIC no realiza cruces contables a nivel de 6 dígitos para provisiones de vivienda y microcrédito. El valor de la garantía tampoco tiene cruce contable específico. Los validadores de negocio sí comparan saldos de capital e intereses contra los grupos contables 14 y 16 del CUIF; los detalles a nivel de subcuenta serán publicados por la SFC en 2026.
Sí. El archivo deberá contener un único registro raíz, dentro del cual se incluirán tres arreglos (arrays), uno para cada insumo del módulo MURIC: créditos, atributos y movimientos. Cada arreglo deberá contener la totalidad de los registros correspondientes a su respectivo insumo, de acuerdo con la estructura y los tipos de datos definidos en el esquema técnico. 

    • Modificación: 22/07/2026